Am besten lässt sich RAG als eine Zwei-Phasen-Architektur verstehen:
- Offline-Indexing (die Datenspeicherung)
- Online-Retrieval (der Chatbot-Laufzeitprozess)
Phase 1: Der Indexing-Prozess (Die Datenspeicherung)
Das ist der entscheidende "Offline"-Schritt, bei dem Wissen vorbereitet wird. Das Ziel ist, unstrukturierten Daten (PDFs, Docs, Webseiten) in ein Format zu bringen, das eine semantische Suche (Sinn-basierte Suche) statt einer reinen Keyword-Suche ermöglicht.
1. Laden (Data Loading)
Zuerst müssen die Rohdaten geladen werden. Dafür gibt es spezialisierte Data Loader (z.B. aus Frameworks wie LlamaIndex oder LangChain).
- PDFLoader liest Text aus PDFs.
- WebBaseLoader scrapt eine Webseite.
- DirectoryLoader lädt alle Files aus einem Ordner.
2. Segmentieren (Chunking)
Man kann kein 100-seitiges PDF auf einmal verarbeiten. Die Daten müssen in handhabbare Stücke, sogenannte "Chunks", zerlegt werden.
Warum?
- Embedding-Qualität: Embedding-Modelle (siehe nächster Punkt) funktionieren am besten mit kurzen, kohärenten Textabschnitten. Context-Limit: Das LLM hat ein begrenztes "Context Window" (z.B. 4k, 16k oder 128k Tokens). Der abgerufene Kontext muss hineinpassen.
- Methoden:Fixed-Size Chunking: Einfach (z.B. "nimm immer 1000 Zeichen"). Schnell, aber "dumm", da es Sätze zerreißen kann.
- Recursive Character Text Splitter: Eine weiter entwickelte Methode, die versucht, an logischen Stellen (Absätze, Sätzen, Wörtern) zu trennen.
- Semantic Chunking: (Fortgeschritten) Nutzt ein Embedding-Modell, um zu erkennen, wo ein semantischer Themenwechsel stattfindet, und schneidet dort.
3. Vektorisieren (Embedding)
Das ist das Herzstück der "Datenspeicherung". Jeder Text-Chunk wird nun in einen numerischen Vektor (ein "Embedding") umgewandelt.
- Was ist das? Ein Vektor ist eine lange Liste von Zahlen (z.B. 384, 768 oder 1536 Dimensionen), die die semantische Bedeutung des Text-Chunks repräsentiert.
- Wie? Mittels eines Embedding-Modells (z.B. text-embedding-ada-002 von OpenAI, all-MiniLM-L6-v2 von Sentence-Transformers oder die neuen text-embedding-3-small).
- Das Ergebnis: Texte mit ähnlicher Bedeutung (z.B. "Wie hoch sind die Versandkosten?" und "Was kostet die Lieferung?") haben Vektoren, die im hochdimensionalen Vektorraum "nah" beieinander liegen.
4. Speichern (Storage & Indexing)
Jetzt kommt die eigentliche Vektor-Datenbank (Vector Database) ins Spiel.
Was wird gespeichert? Für jeden Chunk werden mindestens drei Dinge gespeichert:
- Vektor (die Zahlenliste)
- Original-Text (den Chunk selbst)
- Metadaten (z.B. source: 'dokument_A.pdf', page: 42, chapter: 'Sicherheit')
Warum eine spezielle DB? Eine normale SQL-DB ist sehr schlecht darin, Ähnlichkeit zu finden. Sie kann WHERE text LIKE '%lieferung%', aber nicht "finde Texte, die wie 'Lieferung' klingen".
- Die Technologie: Vektor-Datenbanken (wie Pinecone, Weaviate, Chroma, Milvus, oder pgvector als Postgres-Extension) sind für eine einzige Aufgabe optimiert: Approximate Nearest Neighbor (ANN) Search.
- Der Index: Die DB erstellt einen speziellen Index (z.B. HNSW - Hierarchical Navigable Small Worlds), der es erlaubt, extrem schnell (in Millisekunden) die "nächsten Nachbarn" (die ähnlichsten Vektoren) zu einem neuen Vektor zu finden, ohne jeden einzelnen Vektor in der DB vergleichen zu müssen (was ein O(n) Brute-Force-Scan wäre).
Zusammenfassung Datenspeicherung: Die Wissensbasis ist jetzt kein Text mehr, sondern eine hochoptimierte, durchsuchbare Datenbank von semantischen Vektoren, die auf ihre Originaltexte verweisen.
Phase 2: Der Retrieval-Prozess (Der Chatbot im Betrieb)
Folgende Prozesse laufen ab, wenn ein Nutzer eine Frage stellt.
1. Query Embedding
Der Nutzer tippt eine Frage ein: “Wie sind die Lieferzeiten?”
Diese Frage (der "Query") wird durch dasselbe Embedding-Modell verarbeitet wie die Dokumente in Phase 1.
Ergebnis: Ein Vektor, der die Bedeutung der Nutzerfrage repräsentiert.
2. Vector Search (Das "Retrieval")
Dieser Query-Vektor wird nun an die Vektor-Datenbank gesendet.
- Die DB nutzt ihren HNSW-Index, um die Top-k (z.B. k=5) ähnlichsten Vektoren aus deinem Index zu finden.
- Suchtyp: Die "Nähe" wird meist per Cosinus-Ähnlichkeit (Cosine Similarity) oder Euklidischem Abstand berechnet.
- Filterung (Optional): Hier werden die Metadaten wichtig. Wenn der Nutzer fragt: "Was steht in Dokument A über Lieferzeiten?", kannst du die Suche so filtern: "Finde Top-k Vektoren, WHERE source == 'dokument_A.pdf'".
3. Augmentation (Die "Anreicherung")
Die Datenbank gibt die Top-k Ergebnisse zurück. Das sind nicht nur die Vektoren, sondern die zugehörigen Original-Text-Chunks (die in Schritt 1.4 mitgespeichert werden). Diese Chunks (der "Kontext") werden nun automatisch vor die ursprüngliche Nutzerfrage in einen neuen, größeren Prompt kopiert.
Beispiel-Prompt für das LLM:
Du bist ein hilfreicher Assistent. Antworte auf die Frage des Nutzers
ausschließlich basierend auf dem folgenden Kontext:
--- KONTEXT START ---
[Text-Chunk 3 - aus doc_A.pdf, Seite 5]
"Unsere Standard-Lieferzeit beträgt 3-5 Werktage.
Expresslieferungen erfolgen innerhalb von 24 Stunden."
[Text-Chunk 1 - aus faq.html]
"Bestellungen vor 12 Uhr mittags werden noch am selben Tag bearbeitet.
Die Versandkosten betragen pauschal 4,99 €."
[Text-Chunk 42 - aus agb.pdf, Seite 12]
"Verzögerungen durch höhere Gewalt sind ausgeschlossen..."
--- KONTEXT ENDE ---
Frage des Nutzers: Wie sind die Lieferzeiten?
Antwort:
4. Generation (Die "Generierung")
- Dieser gesamte "augmentierte Prompt" wird an ein LLM (z.B. GPT-4, Llama 3 oder Claude 3) gesendet.
- Das LLM muss nun keine "Weltkenntnis" mehr haben oder raten (halluzinieren). Die Antwort steht direkt im Kontext.
- Das LLM generiert die Antwort: "Die Standard-Lieferzeit beträgt 3-5 Werktage. Expresslieferungen sind innerhalb von 24 Stunden möglich."
Wichtige Überlegungen
- Chunking-Strategie ist entscheidend: Zu kleine Chunks haben keinen Kontext. Zu große Chunks "verwässern" das Embedding und enthalten zu viel "Rauschen" (irrelevante Infos) für den LLM-Prompt.
- Hybride Suche (Hybrid Search): Reine Vektor-Suche ist schlecht bei spezifischen Eigennamen, Produkt-SKUs oder IDs (z.B. "Fehler_404_Fix"). Hier kombiniert man Vektor-Suche (semantisch) mit traditioneller Keyword-Suche (z.B. BM25).
- Optional: Bei nicht optimalen Suchergebnissen erfolgt ein Re-Ranking: Manchmal werden erst Top-k=50 Ergebnisse (schnell, "grob") geholt und dann sorgt ein kleineres, spezialisiertes Re-Ranking-Modell (z.B. Cohere Rerank), um die 50 auf die "echten" Top-k=5 zu sortieren, bevor sie ins LLM gehen (Qualität vs. Latenz).